PBS-style date-keyed releases + Node 24 actions#14
Merged
Conversation
Restructures the publish step so that a manually triggered workflow_dispatch
with a `release_date` input (YYYYMMDD) produces a single GitHub release
tagged by that date, containing every per-platform tarball from every
matrix entry. Mirrors what astral-sh/python-build-standalone already does
and what we already consume in flet-dev/serious-python's package_command
via _release.standaloneReleaseDate.
Why move away from one-release-per-python-minor:
* Re-cutting a release for a build fix (e.g. the Python.app strip we
just landed) currently has to clobber an existing tag, which breaks
reproducibility for any downstream that pinned to it.
* Several platform fixes in the past month had to wait for a coordinated
"all minor versions get a fresh tarball" moment; date tags decouple
that — we just cut a new date once everything we care about builds.
* Symmetric with how flet-dev/serious-python's package_command resolves
its astral-sh CPython tarball: pin a date, not a minor.
Changes:
* build-python.yml:
- workflow_dispatch gains a `release_date` input (YYYYMMDD).
- New publish-release job downloads ALL matrix artifacts and
publishes one release tagged ${release_date}.
- Publish only fires on workflow_dispatch with a non-empty
release_date; pushes still exercise the matrix (artifacts left
for inspection) but don't touch releases.
* build-python-version.yml:
- Removed the per-version publish-release job (moved to parent).
- Matrix artifact upload names now include the full Python version
(e.g. python-darwin-3.14.6 instead of python-darwin-3.14) so the
parent workflow can ingest multiple patch versions of the same
minor without artifact-name collisions.
- Darwin packagers receive the full version directly so their
tarball filenames carry it verbatim.
* Per-platform packagers (darwin/ios, android, linux, windows):
- Tarball/zip filenames switch from $PYTHON_VERSION_SHORT to the
full $PYTHON_VERSION (e.g. python-macos-dart-3.14.6.tar.gz). The
internal lookups that need the short version derive it inline.
- mobile-forge artifacts follow the same naming convention.
Consumer side (serious-python's prepare_*.sh, build.gradle, CMakeLists)
still needs a follow-up to:
- Read a new PYTHON_BUILD_RELEASE (YYYYMMDD) env var instead of using
"v$PYTHON_VERSION" as the release tag.
- Reference tarballs by full Python version in the URL.
- Lay them out as $FLET_CACHE_DIR/python-build/<release>/<file>.
That migration is independent of this PR and will land separately.
The previous releases bundled Node.js 20 runtimes; GitHub deprecated Node 20 in actions on 2026-06-16 with full removal on 2026-09-16, and the workflow now emits a "Node.js 20 actions are deprecated" warning on every matrix entry. v5 ships on Node 24 across all three actions and is otherwise drop-in compatible with our usage. setup-python is already on v6 (Node 24 native). softprops/action-gh- release@v2 still runs on Node 20 — leaving it pending an upstream v3 since it only fires on the new workflow_dispatch publish path and won't add warning noise to push-driven runs.
The earlier v4->v5 bump didn't silence the Node 20 deprecation warnings: actions/upload-artifact@v5 and actions/download-artifact@v5 only have "preliminary" Node 24 support and still default to Node 20. The runtime default flips to Node 24 only at v6+. Move every action to its current latest major (all node24): actions/checkout v5 -> v6 actions/upload-artifact v5 -> v7 actions/download-artifact v5 -> v8 softprops/action-gh-release v2 -> v3 actions/setup-python v6 (already latest, node24) All inputs in use remain supported; artifacts stay zipped so upload v7 / download v8 (direct-upload/decompress changes) and download v8's default digest-mismatch=error don't affect this workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Restructure
python-build's release workflow to mirror whatastral-sh/python-build-standalonedoes: a single GitHub release per date, containing every per-platform
tarball from every Python version in one place. Tarball filenames carry
the full Python version (
3.14.6) so multiple patches of the sameminor can coexist in one release.
Why move off one-release-per-minor
Python.appstrip in #N isthe immediate example) had to clobber an existing
v3.14tag, whichbreaks reproducibility for any downstream that pinned to it.
minors get a fresh tarball" moment. Date tags decouple that — cut a
new date once everything we care about builds, downstreams pick it up
when they bump their
PYTHON_BUILD_RELEASEpin.flet-dev/serious-python'spackage_commandalready pins its
astral-sh/python-build-standalonetarball by date.Changes
build-python.ymlworkflow_dispatchgains arelease_dateinput (YYYYMMDD).publish-releasejob runs after the matrix, downloads everyper-platform artifact, and publishes a single GitHub release tagged
by that date.
workflow_dispatchwith a non-emptyrelease_date. Pushes still exercise the matrix (artifacts availablefor inspection) but never touch releases.
build-python-version.ymlpublish-releasejob removed (moved to parent).(
python-darwin-3.14.6instead ofpython-darwin-3.14) so theparent workflow can ingest multiple patches of the same minor
without artifact-name collisions.
Per-platform packagers (darwin/ios, android, linux, windows)
$PYTHON_VERSION_SHORTto thefull
$PYTHON_VERSION(e.g.python-macos-dart-3.14.6.tar.gz).Internal lookups that need the short version derive it inline.
mobile-forgeartifacts follow the same naming convention.CI hygiene
actions/checkout,actions/upload-artifact,actions/download-artifact, andsoftprops/action-gh-releasetotheir latest majors (Node 24). Clears the 12 Node-20 deprecation
warnings emitted by every matrix entry on the previous run.
Downstream impact (separate PR in
flet-dev/serious-python)After this merges and the first date-keyed release is cut, the five
plugins in
serious-pythonneed a follow-up to:PYTHON_BUILD_RELEASE(YYYYMMDD) env var instead ofcomposing URLs with
v$PYTHON_VERSION.$FLET_CACHE_DIR/python-build/<release>/<file>.That migration is independent of this PR.
Test plan
workflow_dispatchwithrelease_date: <today>,confirm a single release is published with all 4 platforms × 3
Python versions worth of tarballs.
(
python-macos-dart-3.14.6.tar.gz, not…-3.14.tar.gz).softprops/action-gh-release@v3publish stepsucceeds end-to-end.